Threads are instances of software processes operating on a computer system. In operation, when a first user object has a task that needs to be performed, a master thread associates an available worker thread with the user object. Once the task has been completed, the first user object is placed in a wait state until it has another task to be performed and the worker thread is returned to a thread pool to be associated with another user having a task to be performed. When the first user object has another task to be performed, it is likely that a different thread will be assigned thereto to perform that task. Currently, each time a thread is assigned to a user object to perform a task, it must open all of the system resources necessary to perform the task. Similarly, each time a thread is finished performing the task and is returned to the thread pool, it must close all of the resources that have been opened before placing the user object in a wait state. This opening and closing of resources results in a tremendous increase in system resource overhead.
The extra overhead when multiple threads service a user object may include any of the following. First, one database may be held open by multiple threads, causing extra unnecessary network traffic. To alleviate this problem, each thread has to close and open the database, thus replacing the overhead caused by this problem with that caused by the additional opening/closing of the database. If a database fail over occurs, when a user object attempts to open the primary database, underlying technology will redirect the open call to the backup database. For the duration of that operation (i.e., until the database is closed), all requests will go to the backup database. The next time the database is opened, the process will be repeated, with the request first trying to open the primary database until the underlying technology determines that the backup database needs to be attempted. This process often takes a lot of time, resulting in users experiencing latency in operations such as E-mail delivery, over-the-air calendar synchronization, et cetera.
A related problem exists in that a thread can get “hung” or “hung up”. This can occur for many reasons. One reason is that there is contention for system resources such as memory resources, processor resources, and network resources. For example, assuming a first thread locks a resource, when a second thread needs to use the same resource, the second thread will wait for the first thread to release, or unlock, the resource. If the first thread crashes or is for some other reason unable to unlock the resource, the second thread will get hung.
Additionally, a thread could get hung due to an error in a communications subsystem, such as a mail application programming interface (“API”). When a thread makes a call to the subsystem, the thread is locked in and at the mercy of that subsystem. If there is a crash in the subsystem, the thread will be hung. The same scenario also applies on the case of operating systems. It is also possible that the subsystem could get hung itself, which would hang the calling thread.
Finally, a thread could get hung as a result of a network request taking an excessively long time to complete, due to poor network conditions or hardware issues (such as domain controllers being down, routers/repeaters being down), for example. In this scenario, the thread gets hung waiting for the network to return.
Hang up conditions waste valuable processing time and create undesirable overhead as a result of the need to track and monitor the threads that are hung. For the foregoing and other reasons, there exists a need to improve upon the utilization of computer system resources.